【第243期】代码审查就是在排大便——你懂的！

来自早读君：

这个标题如此的有吸引力，但不要有压力，很好看~

正文从这开始~~

豆瓣数据API和后台数据同步已经完成，我大概两天没去管这部分代码，主要是因为产品、老大都不是很积极。因为这个毕竟不是非常重要的。

今天我对代码进行了审查，也进行了一些修复，比如命名规范，代码逻辑，还有就是让整个代码更加符合整个框架的规范（如文件分类，指定文件做它该做的事情）。于是有了想写一篇“代码审查”博文的冲动，故有了此文。

盯哨

作为程序员应该知道Code Review的重要性。我相信很多程序员都不喜欢Code Review，那你喜欢它吗？

在公司两年多，一直是在原有的代码基础上进行代码修复和功能添加。这样势必会经常接触其他人代码，自然而然就养成Code Review的习惯。

在Code Review的时候，我经常感觉我后脑勺发凉，老是觉得有人（呵呵，一般是老大）在盯着我。

1）我有没有偷懒？

2）我有没有完全弄懂逻辑？

3）我写的代码罗不罗嗦？

4）我有没有按照命名规范进行编码？

5）我有没有写出漂亮而完美的代码？...

过程

现在，每次写完代码，我会间隔一段时间翻看旧代码，如果发现不好的地方，我就会去进行修复（这应该就是Code Review了）。

我是一名phper，我不太喜欢使用工具去做这个Review，我喜欢用眼睛看、用脑去思考。

有人说了，你这个不标准，效率不高。——呵呵，毕竟我工作量我自认为不大，所以很多时间我一直在Code Review。

每次看我的代码就像看一件艺术品，我时常问自己，我写的代码我满意吗？还缺点什么？我还能写的更好吗？

感觉

Code Review是个美妙的过程，让我的脑袋从混沌逐渐清晰。刚开始，我会头疼，但是随着你不断的Review，整个思路越来越明朗，代码越来越规范。

人脑是个非常奇特的东西，混沌到清晰是一个痛苦到愉悦的过程。如果长期不经过这个过程，你脑袋很容易锈到。

那么混沌是一个什么感觉？我比较喜欢我外甥的一句话，“脑袋瓜子里就像进入一堆浆糊似的”，他把这个混沌比喻成浆糊。我相信等你把浆糊弄干净了，你脑袋也就清晰了。

再举一个不好听的比喻，就像你把大便从肚子里排除去后的那种感觉。大便越多，最后排出去之后，感觉越爽。所以，你代码中，越有很多理不清的东西，等你真正理清完之后，你的脑子会非常舒服，整个身体都会非常轻松。

方法

我一般如何Code Review呢？

初期：

　　我首先找到一个切入点（也许是一个页面，也许是一个定时执行的脚本main()方法），然后逐个去找类，找方法，直到最后输出。——不停的去理这个过程。

　　然后再找下一个切入点。

后期：

　　我会挑选几个比较常见的业务，没有太明白的业务，然后寻找切入点，在进行以上循环。

话题

周四的时候，也刚好在微信朋友圈讨论这个代码code review的话题，这种话题时不时的冒出来一次，现总结分享下：

@杨青：

1）豆瓣之前用github企业版很简单，每个人的代码都需要另一个人看过后才能合并。这是一个准则，其他规范都在此之上。

2）统一命名方式，代码缩进，这也是普通的团队规范。

3）合并代码，包括leader写的代码也是需要review后才能合并。

4）做代码review的意义：对促进团队团结的效果很好，也能促进团队成员水平的提升，只要有一个牛人就能创造出很多牛人。

5）每个pr通常对应一个trello card，同时会附上产品逻辑背景介绍，尽量拆分细节的pr。每次review的量不一定要很大，但一定不能累计。

6）代码review不一定要很高P才能review，团队中的每个人都可以，特别是review高P写的代码，很舒服

7）一般都是从通用组件开始。

@basecss：

1）分重构与js，约定每周开会拿一两个小时专门做这事，看多少不固定，平时2）大家会去看项目代码，把问题汇总出来一起讨论

3）发现问题的同时也会去完善项目规范

4）现在主要靠人工审查，没有约束说谁看谁的。

5）Code review本身就是一个互相吐槽，互相学习的过程

6）有条不成文的规定，吐槽的同时要拿出理由跟解决方案，避免针对人

7）重要的是要坚持做这个事情，前期可能很难，坚持后就会很轻松

8）让团队的人意识到这个问题的存在

9）遇到的问题应该是前期蛮多人会抵触的，还有就是审查有些东西很难权衡

总结一下：

1）基本以人工审核为主，辅助以jslint工具

2）团队要达成一致，共同提高

3）对事不对人，提出问题的同时并提出解决方案

感谢两位朋友的分享~~~